Many organizations are embracing the paradigm of Model Based Development in their production processes. “Model Based Development” refers to the practice of specifying, analyzing, and implementing systems using a common “model” consisting of a set of block diagrams and associated objects. System implementation typically consists of automatically generating code for portions of the model, particularly portions corresponding to the system's control algorithm.
Graphical modeling environments are an example of software applications that may enable a user to model dynamic systems i.e., systems whose outputs change in response to time or inputs, using a graphical model, such as a block diagram. Some graphical modeling environments also enable simulation and analysis of models. A graphical model may be created using a graphical user interface, such as a graphical model editor. The graphical model depicts relationships between the systems inputs, states, parameters and outputs.
Block diagrams are graphical entities having an “executable meaning” that are created within graphical modeling environments for modeling a dynamic system, and generally comprise one or more graphical objects. For example, a block diagram model of a dynamic system is represented schematically as a first collection of graphical objects, such as nodes, that are interconnected by another set of graphical objects, generally illustrated as lines, which represent logical connections between the first collection of graphical objects. In most block diagramming paradigms, the nodes are referred to as “blocks” and drawn using some form of geometric object (e.g., circle, rectangle, etc.). The line segments are often referred to as “signals”. Signals correspond to the time-varying quantities represented by each line connection and are typically assumed to have values at each time instant. Each node may represent an elemental dynamic system, and the relationships between signals and state variables are defined by sets of equations represented by the nodes. Inherent in the definition of the relationship between the signals and the state variables is the notion of parameters, which are the coefficients of the equations. These equations define a relationship between the input signals, output signals, state, and time, so that each line represents the input and/or output of an associated elemental dynamic system. A line emanating at one node and terminating at another signifies that the output of the first node is an input to the second node. Each distinct input or output on a node is referred to as a port. The source node of a signal writes to the signal at a given time instant when its system equations are solved. The destination nodes of this signal read from the signal when their system equations are being solved. In other instances the connections between nodes are non-causal. That is, the line connecting the first node to the second node does not necessarily mean an output is being provided from the first node to the second node as an input. An example of non-causal connections can be found in models of electrical circuits in which there is no computational directionality. Those skilled in the art will recognize that the term “nodes” does not refer exclusively to elemental dynamic systems but may also include other modeling elements that aid in readability and modularity of block diagrams.
It is worth noting that block diagrams are not exclusively used for representing time-based dynamic systems but also for other models of computation. For example, in Stateflow®, flow charts are block diagrams used to capture behavior of reactive systems and the flow of discrete state changes. Data flow models are block diagrams that describe a graphical programming paradigm where the availability of data is used to initiate the execution of blocks, where a block represents an operation and a line represents execution dependency describing the direction of data flowing between blocks.
In certain instances it may be desirable to view a block diagram model when access to a graphical modeling environment is not available. For example, a user may wish to share a block diagram model design with another user. Traditionally, this was done by providing the second user with a copy of the block diagram model design file. The problem with this is that in order to view the block diagram model design, the second user would require a graphical modeling environment to open and view the block diagram model file. Thus each person who wishes to view a block diagram design would require access to a graphical modeling environment. This can be cost prohibitive as each instance of a graphical modeling environment has a cost associated with it. Thus what is needed is a way to view block diagram models without requiring access to a graphical modeling environment.